s s retroarch

Le développeur @Markus95 propose son GUI RetroArch PS2 on PS4-PS5. Ce n'est pas du natif mais il a le mérite d’exister pour ravir les nostalgiques qui pourront jouer aux ROMS GameBoy - Color, Nes, Snes, GameGear, Master System, Megadrive, Atari 800, Lynx, WonderSwam ou NeoGeo Pocket sur leur console PS4 et/ou PS5. Très simple d'utilisation, tout est automatisé pour créer un FPKG d'émulateur ! Il utilise RetroArch PS2.

La méthode est détaillée dans le tutoriel avec tout ce qu'il vous faut, section:


Une autre section "pourrait" voir le jour. Il s’agit de Backport & Co.. Faudra que je trouve le temps ^^
@Markus95 a également développé un .bat qui vous permettra d'automatiser le processus. A voir

• Lien: Auto_Backport


• Source: Code idlesauce

@nikkko003
Sauf erreur mais depuis, cela a dû évoluer ou être modifié, le maintien de là touche R sert à allouer toute la mémoire au lancement d’un jeu ou d’un homebrew. Cela pourrait être aussi la touche L mais suis pas devant la console pour vérifier. Et pour ce que tu souhaites, je ne m’y suis pas réellement penché dessus et ta demande a un intérêt. Si jamais tu trouves, n’hésites pas à faire un retour de la démarche et je l’ajouterai à la FAQ. Tu peux trouver cela sur GBATemp.

@rotou
Les préconisations sont un peu expliquées en FAQ.
La configuration de l’emuNAND en fichier ou en partition est au choix de l’utilisateur et elle a des avantages dans les deux cas comme elle possède aussi des inconvénients. Cela dépend aussi de la carte SD donc difficile d’étayer le sujet.

Pour ce qui concerne le format, tout le monde s’accorde à dire que le format exFat a tendance à corrompre les données et que le Fat32 est préconisé. D’ailleurs ce dernier est nécessaire à beaucoup d’outils. Et la limite qu’il impose n’a plus lieu d’être avec DBi. Donc oui, le format Fat32 est conseillé.

Mon choix n’est pas figé si bien que j’ai essayé plusieurs configurations en Fat32 par Fichier ou partition et une autre en exFat par partition et Fichier. Depuis, je suis resté en exFat par Fichier sans aucune corruption de données mais cela ne signifie pas qu’il n’y a pas de risque.

Je ne suis pas assez alimenté en termes de recul pour dire si l’un ou l’autre est mieux en termes d’écriture, de lecture des données. La seule confirmation, comme indiquée juste avant, est que le format exfat corrompt les données très souvent sur la Switch car pas adapté et que le format Fat32 permet l’utilisation d’homebrew comme RetroArch et autre. Pour ce qui est de la configuration par partition ou par fichier, cela dépend beaucoup de la SD entre autres aspects mais Hekate s’est beaucoup amélioré pour la prise en charge des SD et autres donc étayer pour chacune ce qui est mieux ou pas, serait trop long ^^

Toutes les questions posées depuis ont leur réponse dans la FAQ qu’il faut lire pour comprendre un peu mieux car là je vais résumer grossièrement !

Le hack n’est pas permanent et si tu redémarres ta console, tu te rends bien compte que rien n’est installé sauf les fichiers NSP (qui eux ne fonctionneront pas puisque le hack n’est pas actif). Le fait d’injecter un payload permet de loader et cela depuis ta SD et non depuis la console. Pour Hekate qui est un custom bootloader, c’est ainsi (et pour d’autres également).

En revanche, en fonction de ce que tu utilises, cela laisse des traces dans la télémétrie d’où le fait de ne pas utiliser sa sysNAND pour les aspects underground et de créer une emuNAND. Les deux sont déliées.

Pour Hekate, il utilise un bootloader personnalisé qui n’est pas celui de Nintendo d’où le fait de ne pas aller sur le online. Il possède trois mode de boot qui utilisent son bootloader donc la connexion est à éviter. En démarrant la console normalement, elle utilise le bootloader de Nintendo. Le hack n’est plus actif.

Rien est installé lorsqu’il s’agit d’utiliser un payload (fichier bin) qui se charge de loader depuis la SD et non depuis la console.

Comme dit plus haut, ce qui modifie la NAND, c’est l’installation de NSP, certains homebrews comme RetroArch, le mode autoRCM car il se charge de corrompre la boot et autres.
La sysNAND, c’est la NAND système de la console et l’emuNAND, c’est la NAND système sur la SD. Donc pour éviter de modifier la NAND système de la console avec l’underground, on crée et on utilise une emuNAND.

Ce sont des jeux legit dits officiels donc si tu es certain d’avoir laissé ta sysNAND clean sans avoir utilisé de hack dessus, tu peux la démarrer normalement et procéder à l’installation des mises à jour et DLC achètés. Si tu as un doute ou que tu n’es pas certain, alors ce sera un risque.

Pour les aspects d’installations de DLC ou update pour les backups de jeu sur l’emuNAND, il s’installe comme un NSP via DBI.

Le hack s’utilise sur l’emuNAND strictement pour laisser la sysNAND propre de toute modification underground.

La sysNAND est la NAND système sur la console et l’emuNAND est la NAND système sur la SD. Les deux sont déliées. Ainsi, les données underground ne transitent que sur l’emuNAND.

Maintenant si tu n’es pas certain d’avoir laissé ta sysNAND clean, ce sera un risque de ban. Personne ne peut confirmer réellement ce que la télémétrie envoie en termes de données sur les serveurs de Nintendo. Ce qui modifie la NAND, ce sont l’installation de NSP, certains hormebrews comme celui que tu utilises, RetroArch et le mode autoRCM.

Hacker sa console, c’est aussi se priver du online comme cela est répété depuis. Être certain d’encourir aucun risque serait présomptueux car une erreur est si vite arrivée bien que des solutions existent pour s’en prémunir.